Skip to main content

Seguridad y Estrategia DevSecOps

El modelo Shift-Left Security incrusta controles rígidos en cada fase del ciclo de vida del software:

Controles de Seguridad Clave​

  • CODEOWNERS: Es imposible inyectar código directo a develop, release/* o main. Se requiere aprobación del equipo asignado.
  • Gestión de Secretos: External Secrets Operator se conecta a HashiCorp Vault. Prohibido commitear contraseñas.
  • Firma de Imágenes (Cosign): Kubernetes rechaza contenedores cuya firma no sea verificable.

Gestión de Versiones y Rollback​

  • Opción A (Git Revert - Recomendada): Se ejecuta el revert en Git, Argo CD detecta el cambio y despliega la versión estable anterior.
  • Opción B (Argo CD UI - Emergencias): Se presiona "Rollback" en la interfaz. Argo CD pausa el Auto-Sync e implementa el ReplicaSet estable en segundos.

Buenas Prácticas Generales (Reglas de Oro)​

(Aquí puedes agrupar las 50 reglas que listaste originalmente en bloques de 10 para GitHub, Jenkins, ArgoCD, Kubernetes y WSO2, manteniendo la estructura para que no sea un bloque de texto tan masivo).

9. Integración con WSO2 API Manager​

El gobierno de APIs se integra directamente en el proceso de entrega continua mediante el enfoque API-as-Code, asegurando que los contratos de integración se mantengan y automaticen de forma limpia.

Ciclo de Promoción API-as-Code​

  1. Definición Declarativa: El archivo de especificación OpenAPI (swagger.yaml) y un archivo de configuración de API de WSO2 (api.yaml) conviven en el repositorio de APIs.
  2. Validación en Pipeline: Jenkins procesa la definición con herramientas de linting para garantizar el cumplimiento de estándares empresariales de nomenclatura y tipado.
  3. Aprovisionamiento automatizado: La CLI apictl ejecuta la importación o actualización del recurso en el entorno destino:
    apictl import-api -f ./api-package -e dev --update=true
  4. Políticas globales: Las políticas de seguridad (ejemplo: validación de tokens OAuth2, protección contra inyecciones SQL en API Gateway) se inyectan automáticamente desde las plantillas corporativas.

10. Flujo Completo de una Liberación y Promoción de Entornos​

Matriz de Promoción de Entornos​

Entorno destinoRama de GitOpsAprobadores RequeridosTag de ContenedorControl de SincronizaciónEvidencia Registrada
DEVdevNinguno (Automático tras Merge en develop de App)#BUILD_NUMBER (Ej: 122)Automático (Self-Heal y Prune activos)Logs de Jenkins y Commit firmado del Bot de DevOps.
UATuatLíder Técnico / DevOps Lead#BUILD_NUMBER (Misma de DEV validada)Sincronización Automática al aprobar el PRPR Aprobado en GitHub con aprobación del Tech Lead.
PRODmainProduct Owner y Arquitecto Enterprise#BUILD_NUMBER (Imagen Certificada)Sincronización Manual (Disparada vía UI/Git o programada)Registro del PR en GitHub con doble firma aprobatoria y Release Tag generado.

11. Seguridad y Estrategia DevSecOps​

El modelo Shift-Left Security incrusta controles rígidos en cada fase del ciclo de vida del software:

Controles de Seguridad Clave​

  • CODEOWNERS y Branch Protection: Es imposible inyectar código directo a develop, release/* o main. Se requiere obligatoriamente aprobación del equipo asignado en el archivo CODEOWNERS:
    # Archivo CODEOWNERS en GitHub
    * @alpura-enterprise/devops-architects
    /src/main/ @alpura-enterprise/backend-leads
    /pom.xml @alpura-enterprise/backend-leads
  • Gestión de Secretos: Está estrictamente prohibido commitear contraseñas, tokens o llaves API en Git. Las aplicaciones leen referencias ficticias. Un operador dentro de Kubernetes (External Secrets Operator) se conecta a HashiCorp Vault, recupera los secretos y crea Secrets nativos efímeros en RAM de K8s.
  • Firma de Imágenes con Cosign: Las imágenes que pasan con éxito las pruebas y el escaneo de Trivy son firmadas usando una clave privada de organización. Kubernetes (a través de un controlador de admisión como Kyverno) rechaza la ejecución de cualquier contenedor cuya firma no sea verificable.

12. Gestión de Versiones y Estrategia de Rollback​

Versionado Semántico (SemVer 2.0.0)​

Cada microservicio utiliza el formato MAJOR.MINOR.PATCH:

  • MAJOR: Cambios incompatibles con la API actual.
  • MINOR: Nuevas funcionalidades retrocompatibles.
  • PATCH: Corrección de errores que no rompen nada.

### Flujos de Rollback Comparados

Flujos de Rollback Comparados​